Looking at the current docs we have, I'm wondering how we can make this more user friendly. Perhaps having something like app.release.androidApk , with release being an inner trait, or app.androidReleaseApk but I think with mill's design the former could work better. Of course this is not in the scope of this PR

Lgtm

While it's good to document the status quo, we should aim for a dedicated release module, so the user can maintain it in parallel to the dev/debug build. This could be either a sub-module (deriving most of it's settings from the outer module) or a cross-axis.

While it's good to document the status quo, we should aim for a dedicated release module, so the user can maintain it in parallel to the dev/debug build. This could be either a sub-module (deriving most of it's settings from the outer module) or a cross-axis.

I agree, I've played a bit with some flows, I haven't decided yet the best approach, I tried mixing a trait first but that has some complications.

The best "interface" I came up with so far is a release module (like the androidTest) where you will be able to do ./mill app.release.compile or ./mill app.release.androidApk

I'll get that into a proper PR soon

EDIT: what is a cross-axis?

EDIT: what is a cross-axis?

One parameter (of potentially many parameters) of a cross module. E.g. Making an Android module a cross-module with a release parameter.

EDIT: what is a cross-axis?

One parameter (of potentially many parameters) of a cross module. E.g. Making an Android module a cross-module with a release parameter.

Thanks, I think I get it and it may actually be a better fit than what I was going for, I will give it a go

From a usability aspect, I think I prefer the sub-module approach. the most trivial reason is, that you don't need to provide any parameters. Many web-frameworks like Vaadin also have a notion of prodcution builds. Those typically need additional settings that can be ignored in development builds like release keys, minification setup, extra compile and bundling steps. When using a cross-module, those settings missing is probably harder to model.

The thing is, there maybe more build types than debug and release, which is why I keep delaying this until we are happy feature wise and tested various apps, so we won't have the extra complexity of build variants.

I'll need to experiment more with this, I think now we are in a good place with features and we can start looking at different variants (e.g. some apps have a performance profiling variant).

I'll tag you to the related PRs so we can discuss more on concrete examples/implementations, I don't expect to get this right from the first try, but let's see how it goes